Git协同工作流，你该怎么选？-[2026重制版]

pull → commit → push (冲突时 pull --rebase)

checkout -b feature → 开发 → push → PR → 合并到master

# trunk_based_development.yaml
# TBD核心规则
 
principles:
  # 规则1：主干始终可发布
  trunk_always_deployable:
    description: "trunk/main分支的代码必须随时可以部署到生产环境"
    enforcement:
      - CI必须全部通过才能合并
      - 必须有至少1个Approval
      - 必须通过自动化测试（单元+集成+E2E）
 
  # 规则2：短生命周期分支
  short_lived_branches:
    max_lifetime_hours: 24      # 分支存在不超过1天
    max_commits: 10             # 不超过10个commit
    ideal_commits: 1            # 最佳：1个commit完成一个feature
    rationale: "分支越短，冲突越少，集成越快"
 
  # 规则3：持续集成
  continuous_integration:
    frequency: "每次push触发CI"
    feedback_time_target_minutes: 15  # 目标15分钟内得到CI结果
    test_coverage_threshold: 80     # 新增代码覆盖率不低于80%
 
  # 规则4：Feature Flags管理未完成的功能
  feature_flags:
    usage: "将未完成的代码合入主干，通过开关控制是否对用户可见"
    tools:
      - LaunchDarkly
      - Unleash
      - Optimizely
      - 自实现（基于配置中心）
    types:
      release_flags: "发布开关（控制新版本灰度）"
      experiment_flags: "实验开关（A/B测试）"
      ops_flags: "运维开关（限流、降级）"
      permission_flags: "权限开关（功能访问控制）"
 
# TBD工作流示例
workflow:
  step_1:
    action: "从trunk拉取最新代码"
    command: "git checkout main && git pull"
 
  step_2:
    action: "创建短命分支"
    command: "git checkout -b feature/user-auth-oauth2"
    note: "分支名以feature/fix/hotfix/chore开头"
 
  step_3:
    action: "开发和提交（尽量少次数）"
    best_practice: |
      完成一个小的、完整的改动
      不要WIP（Work In Progress）提交
      如果改动大，拆分成多个独立的PR
 
  step_4:
    action: "Push并创建PR"
    command: "git push origin feature/user-auth-oauth2"
    automation: "自动创建Draft PR或直接打开PR"
 
  step_5:
    action: "CI自动运行"
    checks:
      - Lint检查
      - Unit Tests
      - Integration Tests
      - Security Scan (SAST/DAST)
      - Build Verification
 
  step_6:
    action: "Code Review"
    reviewers: "至少1人，可以是AI辅助"
    criteria:
      - 逻辑正确性
      - 测试覆盖
      - 性能影响评估
      - 安全性审查
 
  step_7:
    action: "合并到主干"
    method: "Squash Merge（推荐）或 Rebase Merge"
    automation: "合并后自动触发部署pipeline"
 
  step_8:
    action: "删除远程分支"
    cleanup: "保持仓库整洁"

# github_flow_enhanced.yaml
# 适用于大多数团队的GitHub Flow配置
 
repository_settings:
  protection_rules:
    main_branch:
      required_status_checks:
        strict: true          # PR必须基于最新的main
        contexts:
          - ci/lint
          - ci/test-unit
          - ci/test-integration
          - ci/test-e2e
          - security/sast
          - security/dependencies
      required_pull_request_reviews:
        dismiss_stale_reviews: true   # 新push后重新review
        require_code_owner_review: false  # 可选：要求代码owner review
        required_approving_review_count: 1
      bypass_pull_request_allowances: []  # 谁可以跳过review（通常为空）
 
branch_protection:
  - pattern: "main"
    required_status_checks: [see above]
    enforce_admins: true              # 管理员也遵守规则
    allow_force_pushes: false         # 禁止force push到main
    allow_deletions: false            # 禁止删除main
 
automations:
  on_pull_request:
    - action: "auto-assign-reviewer"
      config:
        strategy: "round-robin"       # 或 "random", "load-balanced"
        exclude_author: true           # 不分配给作者自己
        max_reviewers: 2
 
    - action: "add-labels-based-on-files"
      config:
        "*.py": ["python", "backend"]
        "*.tsx": ["typescript", "frontend"]
        "Dockerfile*": ["devops", "infrastructure"]
 
    - action: "ai-code-review"
      tool: "GitHub Copilot Code Review"  # 或其他AI Review工具
      config:
        focus_on:
          - potential_bugs
          - security_issues
          - performance_antipatterns
          - code_style_violations
        language: "zh-CN"               # Review语言
 
  on_merge:
    - action: "delete-branch"
      config:
        except_branches: ["main", "develop", "staging-*"]
 
    - action: "trigger-deployment"
      config:
        environment: "staging"          # 先发staging验证
        auto_production: false            # 生产需手动确认
 
    - action: "update-documentation"
      config:
        generate_changelog: true
        update_api_docs: true
 
code_review_guidelines:
  checklist:
    - "代码逻辑正确且符合需求？"
    - "有足够的单元测试覆盖新增/修改的逻辑？"
    - "没有引入安全漏洞？（依赖版本、敏感信息硬编码等）"
    - "没有明显的性能问题？（N+1查询、内存泄漏等）"
    - "错误处理完善？（边界条件、异常情况）"
    - "日志和监控埋点充分？"
    - "代码风格一致？（命名、结构、注释）"
 
  response_sla:
    normal_pr: "24小时内首次响应"
    urgent_pr: "4小时内首次响应"
    blocking_pr: "1小时内响应"

// nx.json
{
  "$schema": "./node_modules/nx/schemas/nx-schema.json",
  "namedInputs": {
    "default": ["{projectRoot}/**/*.ts", "{projectRoot}/**/*.tsx"],
    "production": [
      "default",
      "!{projectRoot}/**/*.spec.ts",
      "!{projectRoot}/**/*.test.tsx"
    ]
  },
  "targetDefaults": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["production"],
      "cache": true
    },
    "test": {
      "inputs": ["default", "^production"],
      "cache": true
    },
    "lint": {
      "inputs": ["default"]
    }
  },
  "tasksRunnerOptions": {
    "default": {
        "runner": "nx/tasks-runners/default",
        "options": {
          "cacheableOperations": ["build", "test", "lint", "e2e"]
        }
      }
  },
  "affected": {
    "defaultBase": "main"
  },
  "workspaceLayout": {
    "appsDir": "apps",
    "libsDir": "packages"
  },
  "generators": {
    "@nx/react:library": {
      "buildable": true,
      "publishable": true,
      "importPath": "@myorg/shared-{name}"
    }
  }
}

# 只构建受影响的项目
nx affected:build
 
# 只测试受影响项目的测试
nx affected:test
 
# 查看某个变更会影响哪些项目
nx print-affected --files=packages/shared/src/utils.ts
 
# 图形化查看依赖关系
nx graph
 
# 一次性运行多个项目的任务
nx run-many -t build -p web-app api-server mobile-app

# ai_code_review_config.yaml
# AI Code Review 配置
 
providers:
  openai_codex:
    model: "gpt-4o"
    system_prompt: |
      你是一个资深代码审查员。请从以下维度审查代码：
      1. 正确性：逻辑是否正确？是否有bug？
      2. 安全性：是否有安全风险？
      3. 性能：是否有明显的性能问题？
      4. 可维护性：代码是否清晰易懂？
      5. 测试：测试覆盖是否充分？
 
      请用中文回复，格式如下：
      ✅ 做得好的地方：...
      ⚠️ 需要注意的地方：...
      ❌ 建议修改的地方：...
 
  github_copilot:
    enabled: true
    instructions: |
      - 关注业务逻辑正确性
      - 检查潜在的空指针/越界访问
      - 建议更Pythonic/Rustace/Idiomatic的写法
 
  custom_rules:
    - name: "no-hardcoded-secrets"
      pattern: "(password|secret|api_key)\s*=\s*[\"'][^\"']+[\"']"
      severity: "error"
      message: "检测到可能的硬编码密钥，请使用环境变量或密钥管理服务"
 
    - name: "require-error-handling"
      pattern: "(fetch|axios|request)\("
      check: "后续代码是否包含 .catch( 或 try-catch"
      severity: "warning"
      message: "异步请求缺少错误处理"
 
review_workflow:
  trigger: "on_pull_request_opened, on_pull_request_synchronize"
 
  phases:
    - name: "automated_checks"
      actions:
        - run_linter
        - run_unit_tests
        - run_security_scan
        - check_dependencies_vulnerabilities
      timeout: 10min
 
    - name: "ai_initial_review"
      actions:
        - ai_analyze_diff
        - generate_suggestions
      runs_on: "bot_account"
      timeout: 5min
 
    - name: "human_review"
      assignees: "auto-selected based on CODEOWNERS file or round-robin"
      requirements:
        - at_least_one_approval
        - no_outstanding_change_requests
      timeout: 48h  # 给人类 reviewer 足够时间
 
    - name: "ai_final_check"
      trigger: "before_merge"
      actions:
        - verify_all_comments_addressed
        - check_for_regressions
      auto_approve_if: "all automated checks pass AND all suggestions addressed"
 
output_format:
  inline_comments: true          # 在代码行旁边评论
  summary_comment: true          # PR总体评价
  severity_emoji: true           # 用emoji标识严重程度
  actionable_only: true           # 只给出可操作的建议

## 迁移路线图（建议耗时：2-4周）
 
### Week 1: 准备阶段
- [ ] 与团队沟通变更原因和收益
- [ ] 更新Branch Protection Rules
- [ ] 配置CI/CD pipeline（确保质量门禁）
- [ ] 选择试点项目/团队
 
### Week 2: 试点阶段
- [ ] 试点团队切换到新模式
- [ ] 收集反馈和问题
- [ ] 调整配置和流程
- [ ] 编写新的Team Handbook
 
### Week 3: 全面推广
- [ ] 全团队培训新工作流
- [ ] 清理旧的长期分支
- [ ] 建立Feature Flags机制（如需要）
- [ ] 监控关键指标（合并频率、CI通过率、部署频率）
 
### Week 4+: 优化阶段
- [ ] 引入AI Code Review
- [ ] 优化CI速度（缓存、并行化）
- [ ] 定期Review工作流效果
- [ ] 持续改进